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Remarks 

/. Confirmation of Election 

The applicant confirms his election, without traverse, of Group I Species I (e.g. 
claims 1, 3-4, 8-11, 13-14, 16-17, 19, 20-21, 23, and 27). The unelected claims (e.g. 
claims 2, 5-7, 12, 15, 18, 22, 24-26, and 28-34) have been canceled. 

//. REJECTION OF CLAIMS UNDER 35 USC 103. 

Claims 1,3-4, 8-11, 13-14, 16-17, 19, 20-21, 23, and 27 stand rejected under 35 
USC 103(a) as being unpatentable over US Patent 6,173,272B1 to Thomas et al. in 
view of US Patent 6,640,244 to Bowman-Amuah. 

General Discussion 

Thomas et al. discloses a solution for using an electronic fund transfer (ACH) to 
replace a traditional paper check as the form of payment of a bill. 

In the business to business field, payment of invoices by paper check remains 
prevalent because: i) the payer's account's payable system can easily print a paper 
check so long as the name of the payee and the amount is known; and ii) the check is 
easily associated with a remittance stub (either printed with the check or associated 
with a payment stub provided by the biller); and iii) the check can be sent to the biller by 
knowing only the biller's mailing address. 

Use of ACH for payment of invoices in the business to business field is not wide 
spread. Some of the challenges with using ACH include: i) the payer must know the 
biller's bank routing number and account number to initiate a payment (and maintain 
the accuracy of such information in the accounts payable system); and ii) the payer 
must associate the ACH payment with an invoice without use of a paper remittance 
stub. 
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In general Thomas et al. proposes a centralized database of bank routing and 
account numbers so that a payer can initiate an ACH payment without having to know 
the payee/biller's bank routing and account number. 

The teachings of Thomas et al. are useful based on the following assumptions: i) 
that all US accounts can be identified by a unique universal identifier (UID) on the order 
of 6 characters in length; and ii) a trusted third party can maintain a database that 
associates each UID with a bank routing number and account number needed to send 
an ACH payment to the account. 

Thomas et al. teaches that the payer's bank would maintain a database 
associating the name, address, and other non-confidential information of the account 
holder with the UID. The payer's bank would not have access to the confidential routing 
number and account number which are maintained by the trusted third party. 

The payer would generate a typical ACH payment transaction but, without 
access to the payee's bank routing number and the account number, the payer would 
instead include the UID in the ACH transaction account number field and a 
predetermined code (such as all "9"s) in the routing number field. The ACH payment 
transaction would then be routed to the trusted third party. 

The trusted third party would: i) replace the UID and the predetermined code with 
the payee's confidential bank routing number and account number; and ii) enter the 
transaction into the ACH network wherein the payment is executed. 

Effectively, the system of Thomas et al. is a "conduit" which: i) receives an ACH 
payment transaction, ii) translates the address of the otherwise standard ACH payment 
transaction; and iii) forwards the transaction to the ACH payment network. 

Thomas further teaches that the system can be used in reverse for delivering 
bills. A biller can provide an electronic billing transaction (for example a bill in the ASC 
X12 format) which includes the UID of a consumer's bank account. The trusted third 
party would: i) replace the UID with the applicable bank routing number and account 
number of the consumer; and ii) forward the transaction into the network such that the 
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X12 transaction can be delivered to the consumer's bank - and presumably delivered 
by the consumer's bank to the customer. The X1 2 transaction includes all data needed 
to generate a remittance transaction to accompany an ACH payment back to the biller. 

It must be appreciated that the Thomas et al. system is strictly a "conduit" for 
address translating and forwarding electronic transactions between the biller and the 
consumer. 

Thomas fails to address the fact that in the business to business invoicing and 
payment field, the biller is using its own accounts receivables system and the payer is 
using its own accounting systems with an accounts payable module - which do not 
have compatibility between the two. 

The applicant's invention, is not just a conduit for passing transactions between a 
biller and a customer, but an automated invoice management system with which both 
the biller's accounts receivable system and the payer's account's payable system 
interact to automate the process of invoice presentment, invoice adjustment, and 
invoice payment - even when the transaction formats between the biller's accounts 
receivable system and the payer's accounts payable system are incompatible. 

More specifically, an automated invoice management system is a database 
system into which a biller delivers invoices using an invoice file format compatible with 
the biller's accounts receivables system (P15L12-P19,L6). The data base includes not 
only the delivered invoices (in a standardized format), but also includes status 
information (e.g. data related to the invoice dispute, approval, and payment process) 
which can be entered by either the biller or the payer P71 ,L5-L23). Further, the 
database includes biller profile information and payer profile information and systems 
which use such profile information, in conjunction with a payment authorization by the 
payer, to generate a remittance transaction that is associated with the invoice 
transaction (P67,L3-P68,L17). 

Both the biller and payer can generate reports from the database such that: i) the 

invoice data can be retrieved by the payer using file formats compatible with the payers 
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AP system (P69L20-P71 ,L4); and the invoice status within the dispute, approval, and 
payment process may be monitored by both the biller and the payer (P35,L19-36L19) 
and P72,L1-L10); and by obtaining a report the includes the remittance transaction, the 
biller can obtain data related to both the remittance transaction and the associated 
invoice in a format that automatically posts the reconciliation to the biller's AR system. 

Claim 1 

Claim 1 , as amended is directed to an automated invoice management system 
for communication with at least one biller system of a biller and at least one payer 
system of a payer. The automated invoice management system comprises a database, 
an invoice loader, and an application server. 

The database includes: i) invoice data in a standardized data structure, ii) status 
information related to adjustment, approval, and payment of each invoice represented 
by the invoice data, iii) biller profile information, and iv) payer profile information relating 
to said biller system and said payer system respectively and to the business 
relationship between the biller and the payer, and 

The invoice loader: i) receives invoice data from said biller system, ii) translates 
the invoice data to a standardized data structure, and iii) stores such invoice data in the 
database. 

The application server: i) stores at least one modular business object containing 
specified instructions to govern financial transactions between said biller system and 
said payer system based on said global information; ii) executes said business object 
upon instruction from at least one of the payer system and the biller system to modify at 
least one of the invoice data and invoice status data in accordance with the specified 
instructions to govern financial transactions between said biller system and said payer 
system included within at least one of the biller profile information and the payer profile 
information; and iii) enables replacement of said business object with another modular 
business object containing other specified instructions using the same said biller profile 
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information and payer profile information to reflect an alteration of the business 
relationship between the biller and the payer. 

Neither Thomas et al., Bowman-Amuah, nor the other art of record teaches a 
combination of such elements. 

Claims 8-11, 13, 14, 16, 17, and 19-21 

Each of Claims 8-11, 13, 14, 16, 17, and 19-21 depend from Claim 1 and can be 
distinguished over Thomas et al., Bowman-Amuah, and the other art of record for at 
least the same reasons. Further, the limitations recited in each such dependent claim 
further distinguishes the claimed inventions over Thomas et al., Bowman-Amuah, and 
the other art of record 

///. CONCLUSION. 

In view of the amendments made herein, claims 1 , 8-1 1 , 1 3, 1 4, 1 6, 1 7, and 1 9- 
21 are believed to be allowable and the application is believed to be in condition for 
allowance. A prompt action to such end is earnestly solicited. 

Should the examiner feel that a telephone interview would be helpful to facilitate 
favorable prosecution of the above identified application, the Examiner is invited to 
contact the undersigned at the telephone number provided below. 

Should a petition for an extension of time be necessary for the timely reply to the 
outstanding Office Action or should additional claim fees be necessary, the Commission 
is authorized to charge any fees to Deposit Account No 105825. 




Timothy P. O'Hagan 
Reg. No. 39,391 
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